REMARKS 



No claims have been amended, added or cancelled. Claims 1-31 are pending in 
the application. Reconsideration is respectfully requested in light of the following 
remarks. 

Section 112, Second Paraeraph, Rejection : 

The Examiner rejected claim 8 under 35 U.S.C. § 112, second paragraph, as 
indefinite. Specifically, the Examiner asserts that the "substantially" is a relative term 
rendering claim 8 indefinite. Applicants respectfully traverse this rejection and submit 
that claim 8 is not indefinite. Contrary to the Examiner's assertion, one of ordinary skill 
in the art would easily ascertain the scope of the claim. Use of the term "substantially" 
does not necessarily render a claim indefinite. As noted in the M.P.E.P. at §2173.05(b)D, 
the courts have held that limitation "which produces substantially equal E and H plane 
illumination pattern" was definite because one of ordinary skill in the art would know 
what was meant by "substantially equal." Similarly, one of ordinary skill in the art would 
easily understand the phrase "a substantially identical view", as recited in claim 8. From 
Applicants' disclosure, one of ordinary skill in the art of distributed computing would 
easily recognize that if a gateway was distributed over a plurality of servers, the 
implementation may not be exactly identical on each server, e.g., due to variations in the 
particulars of each server platform; however, the servers would still present a 
substantially identical view of the gateway. Thus, Applicants respectfully request 
removal of the § 112 rejection of claim 8. 

Section 102(e) Rejection : 

The Examiner rejected claims 1-5, 7-12, 14 and 17-31 under 35 U.S.C. § 102(e) 
as being anticipated by Carre (U.S. Patent 6,282,579). Applicants respectfully traverse 
this rejection for at least the reasons below. 
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Regarding claim 1, Carre fails to disclose a client generating a request for 
type information for an attribute or event, contrary to the Examiner's contention. 

The Examiner cites the Abstract, FIG. 2 A, 2B, as well as column 3, lines 18-55 and 
column 5, lines 4-38 of Carre. However, Carre does not mention anything about a client 
generating a request for type information, either at the Examiner's cited passages or 
elsewhere. Carre pertains to address conversion between CORBA objects and OSI 
objects (Carre - col. 1, lines 9-19; col. 1, line 59 - col. 2, line 46) and to the transforming 
of object interfaces column 5, lines 49-59). Carre teaches a system in which CORBA 
interfaces and messages are used to communicate with and request services from 
managed objects. In order to permit address interaction between objects that use different 
addressing modes, Carre's system converts an address type with an address value 
according to one addressing mode to a corresponding type of another specification 
language or addressing mode. (Carre, column 1, line 59 - column 2, line 6; column 2, 
lines 11-14; lines 25-28; and lines 34- 39). Thus, Carre is concerned with converting 
address types and object interfaces, but fails to teach anything regarding a client 
generating a request for type information. 

Carre teaches that client objects request services provided by service objects. 
Carre further teaches that a client object sends a request message to a service object that 
contains an operation, a target object, one or more parameters, and, optionally, a request 
context (Carre, column 3, lines 47-53). Carre also teaches that Object Request Brokers 
(ORBs) uses a Remote Procedure Call (RPC) mechanism to route request messages to the 
target object (Carre, column 4, lines 1-6). In order to allow objects defined using 
different specifications, such as ASN.l and DDL, Carre teaches that the objects and 
addresses are converted between the two standards. However, Carre does not mention 
anything regarding a client generating a request for type information for an attribute or 
event. The clients in Carre's system do not request type information, but instead request 
a specific service from a particular server object and Carre's system automatically makes 
any conversions between different object specification languages necessarily to allow the 
client and server object to communicate. Thus, there is no need in Carre's system for a 
client to generate a request for type information for an attribute or event. In fact, the 
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purpose of Carre's teachings appears to be to perform the address type conversion for the 
client so that the client does not have to modify it's own interface in order to 
communicate with an object employing a different addressing mode. See, e.g., col. 1, line 
43 - col. 2, line 6. Therefore, Carre actually teaches away from a client generating a 
request for type information for an attribute or event. 

Carre also fails to disclose sending the request for type information to an 
object request broker. The Examiner cites the Object Request Broker of FIG. 3a of 
Carre. However, FIG. 3a illustrates a CMISE gateway to aid communication between 
objects by converting ASN types to a corresponding IDL types. FIG. 3a does not 
illustrate a client sending a request for type information to an object request broker. As 
noted above, clients of Carre's system send specific request messages to Object Request 
Brokers that include an operation, a target object, one or more parameters, and, 
optionally, a request context. Clients in Carre's system do not send requests for type 
information to object request brokers. 

Carre further fails to disclose a metadata gateway receiving the request for 
type information from the object request broker. The Examiner cites the CMISE 
Gateway of FIG. 3a and column 5, lines 39-65. However, the cited passage does not 
mention anything about a metadata gateway receiving a request for type information from 
an object request broker. As noted above, FIG. 3a also fails to show anything about a 
metadata gateway receiving a request for type information. Carre teaches that by 
converting objects from the ASN.l specification to the IDL specification CMISE 
operations can be performed on CORBA objects, and vice versa (column 5, lines 24-39 
and lines 60-65) but fails to teach anything about a metadata gateway receiving a request 
for type information from an object request broker. Nowhere does Carre describe that his 
CMISE gateway, cited by the Examiner, receives a request for type information from an 
object request broker. 

Carre additionally does not disclose reading the type information from a 
metadata repository. The Examiner cites CMISE/IDL FIG. 3. However, the cited 
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CMISE/IDL is not a metadata repository from which type information is read. Carre 
teaches that the CMISE/IDL is an "interface unit" that contains the "CMISE object and 
the services assigned to this object". Carre also teaches that the CMISE object is 
specified by an IDL interface and acts, and thus appears, like a CORBA object. Thus, the 
CMISE/IDL cited by the Examiner is clearly a communication interface that allows non- 
CORBA objects to be interacted with via standard CORBA interfaces (Carre, column 5, 
lines 21-39). The CMISE/IDL interface unit is clearly not a metadata repository. 
Moreover, Carre does not describe or even mention anything regarding reading type 
information from the CMISE/IDL interface unit. 

Carre also fails to disclose the client receiving the translated type 
information for the attribute or event through the object request broker. The 

Examiner cites column 6, lines 10-35 of Carre. However, this portion of Carre does not 
describe a client receiving the translated type information for the attribute or event 
through the object request broker. Instead, the cited passage is part of a description of 
converting objects from ASN to IDL and vice versa as well as caching of converting 
object instances. As described above, converting CMISE and CORBA objects is not the 
same as client generating a request to type information, and receiving the translated type 
information for the attribute or event through an object request broker. The Examiner's 
cited passage makes no mention of any client receiving translated type information for an 
attribute or event through an object request broker. 

Anticipation requires the presence in a single prior art reference disclosure of each 
and every limitation of the claimed invention, arranged as in the claim . M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shown in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Carre fails to disclose a client generating a request for 
type information for an attribute or event, a metadata gateway receiving the request for 
type information from an object request broker, reading the type information from a 
metadata repository, and the client receiving translated type information for the attribute 
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or event through an object request broker. Therefore, Carre clearly cannot be said to 
anticipate claim 1. 

For at least the reasons given above, the rejection of claim 1 is not supported by 
the prior art and removal thereof is respectfully requested. Similar remarks as those 
above regarding claim 1 also apply to claim 22. 

Regarding claim 2, Carre does not disclose translating the type information from 
the database format to an abstract syntax notation and translating the type information 
from the abstract syntax notation to the interface definition language. The Examiner cites 
column 1, lines 34-55 and column 5, line 60 - column 6, line 21, specifically referring to 
Carre's teachings regarding using semantic conversions. However, the cited passages, as 
well as the remainder of Carre, only describe converting address values from abstract 
syntax notation to interface definition language. For example, Carre teaches that an OSI 
address value is converted to a correspondent IDL type (Carre, column 6, lines 1-2). 
Please note that Carre teaches that OSI objects are specified in ASN (Carre, column 1, 
lines 40-42). Thus, the Examiner's cited passages describe converting between ASN and 
IDL (and the reverse), but fail to mention anything about translating from a database 
format to an abstract syntax notation. 

For at least the reasons above, the rejection of claim 2 is not supported by the 
prior art and. removal thereof is respectfully requested. Similar remarks apply to claim 
23, as well. 

Regarding claim 10, Carre fails to disclose a client generating a request to encode 
type information for an object, attribute, or event. The Examiner cites the Abstract, FIG. 
2A and 2B as well as column 3, lines 18-55 and column 5, lines 4-38. The Examiner also 
specifically refers to Agent 1 of FIG. 3a, equating Agent 1 to the client of claim 10. 
However, Carre does not, either at the Examiner's cited passages or elsewhere, describe a 
client, either Agent 1 or any other client, generating a request to encode type information 
for an object, attribute, or event. As noted above regarding the rejection of claim 1, Carre 
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is concerned with providing interface and address type conversions to allow objects 
specified according to different specification languages, such as ASN and IDL, to 
communicate and interact with each other by providing interfaces that allow non CORB A 
objects to appear as CORBA objects to the outside world. Clients in Carre's system do 
not generate requests to encode type information for objects, attributes or events. Instead, 
client objects in Carre's system invoke, via a standard CORBA interface, services 
provide by server objects. (Carre, column 1, lines 9-19; column 1, line 59-column 2, line 
46; column 5, lines 49-59). Nowhere does Carre mention a client generating a request to 
encode type information for an object attribute or event. 

Additionally, Carre does not disclose sending the request to an object request 
broker and a metadata gateway receiving the request to encode type information from the 
object request broker. The Examiner cites ORB and CMISE Gateway of FIG. 3a. 
However, Carre does not describe the ORB of FIG. 3a as receiving a request to encode 
type information from a client. Nor does Carre describe the CMISE Gateway as 
receiving the request from the ORB. Instead, Carre teaches object request brokers 
provide an infrastructure that enables objects to communicate in a distributed 
environment such that "it makes no difference to" the requesting objects in which 
computer system or in which form the target object is implemented (Carre, column 3, 
lines 56-63). Carre also teaches that a requesting object sends a request message to an 
object request broker and that the object request broker routes the request message to the 
target object (Carre, column 3, line 64-column 4, line 6). Thus, Carre teaches that object 
request brokers route request messages from a request object to the target object. Carre 
does not mention anything about object request brokers receiving requests to encode type 
information from a client or about a metadata gateway receiving such request from an 
object request broker. 

Carre further fails to disclose storing the type information in a metadata 
repository, where the type information is stored in a database format in the metadata 
repository. The Examiner cites CMISE/IDL of FIG. 3 and column 6, lines 10-35, 
specifically referring to Carre's conversion of address types from OS! types. However, 
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the portions of Carre cited by the Examiner refer to the caching of structures, such as 
object instance values and object reference pairs for addresses already in an entity. 
Caching of object values and references is no the same as storing type information in a 
database format in a metadata repository. Additionally, as noted above regarding the 
rejection of claim 1, the CMISE/IDL interface unit cited by the Examiner is clearly a 
communication interface that allows non-CORBA objects to be interacted with via 
standard CORBA interfaces (Carre, column 5, lines 21-39). The CMISE/IDL interface 
unit is clearly not a metadata repository. Moreover, Carre does not describe or even 
mention anything regarding storing type information in the CMISE/IDL interface unit. 

For at least the reasons presented above, the rejection of claim 10 is not supported 
by the prior art and removal thereof is respectfully requested. Similar remarks as those 
above regarding claim 10 apply to claim 27 as well. 

Regarding claim 11, Carre fails to disclose translating the type information from 
the interface definition language to an abstract syntax notation and translating the type 
information from the abstract syntax notation to the database format . The Examiner cites 
column 1, lines 34-55 and column 5, line 60 - column 6, line 21, specifically referring to 
Carre's use of semantic conversions. However, the cited passages, as well as the 
remainder of Carre, only describe converting address values from abstract syntax notation 
to interface definition language and from interface definition language to abstract syntax 
notation. For example, Carre teaches that an OSI address value is converted to a 
correspondent IDL type (Carre, column 6, lines 1-2). Please note that Carre teaches that 
OSI objects are specified in ASN (Carre, column 1, lines 40-42). Thus, the Examiner's 
cited passages describe converting between ASN and IDL (and the reverse), but fail to 
mention anything about translating from an abstract syntax notation to a database format. 
Thus, the rejection of claim 1 1 is not supported by the prior art and removal thereof is 
respectfully requested. Similar remarks also apply to claim 28. 

Regarding claim 14, Carre fails to disclose a metadata repository comprising 
metadata concerning object classes for a plurality of managed objects, wherein the 
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metadata comprises information expressed in a database format, and wherein the 
managed objects correspond to managed devices on a network. The Examiner cites 
CMISE/IDL of FIG. 3a as well as the abstract, FIGs 2A, 3A, column 3, lines 18-55 and 
column 5, lines 4-38 of Carre. However, as noted above, regarding the rejections of 
claim 1 and 10, the CMISE/IDL interface unit cited by the Examiner is clearly a 
communication interface that allows non-CORBA objects to be interacted with via 
standard CORBA interfaces (Carre, column 5, lines 21-39). The CMISE/IDL interface 
unit is clearly not a metadata repository. Moreover, Carre does not describe or even 
mention anything regarding storing metadata concerning object classes in the 
CMISE/IDL interface unit. Nowhere does Carre describe anything about storing 
metadata concerning object classes in a metadata repository. 

Carre also fails to disclose a metadata gateway coupled to the metadata repository 
and to an object request broker, where the metadata gateway is operable to send and 
receive metadata from the database, where the metadata gateway provides translation of 
the metadata to and from the database format and an interface definition language. The 
Examiner cites CMISE Gateway of FIG. 3a. However, Carre's CMISE Gateway 
provides address type conversion between two different object interface specifications, 
such as between IDL and C++, as illustrated in FIG. 3a. Carre's CMISE gateway is not 
coupled to a metadata repository. As noted above, the CMISE/IDL interface unit cited by 
the Examiner is clearly not a metadata repository (and neither is the CMISE/C++ 
interface unit) and thus the CMISE Gateway is not coupled to metadata repository. 
Nowhere does Carre describe his CMISE Gateway as being coupled to a metadata 
repository. Furthermore, Carre's CMISE Gateway is not operable to send and receive 
metadata. Instead, as shown above, the CMISE Gateway translates object interfaces as 
expressed via CORBA RPC request messages (Carre, column 3, line 54 - column 4, lines 
16; and column 5, line 60 - column 6, line 9). 

Additionally, Carre fails to disclose where the metadata gateway provides 
translation of the metadata to and from the database format and an interface definition 
language. As noted above, Carre's CMISE Gateway provides address type conversion 
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between two different object interface specifications, such as between IDL and C++, not 
between a database format and IDL. As noted above regarding the rejection of claim 2, 
Carre does not mention anything regarding converting metadata to or from a database 
format. 

Thus, for at least the reasons presented above, the rejection of claim 14 is not 
supported by the prior art and removal thereof is respectfully requested. 

Regarding claim 17, Carre fails to disclose wherein the metadata gateway 
includes a library of data types expressed in an abstract syntax notation , a plurality of 
object types, wherein each object type includes one or more of the data types from the 
library of data types. The Examiner cites, FIG. 2A, 3 A, column 4, lines 7-62 and column 
5, line 39 to column 6, line 35 of Carre. However, the Examiner has failed to cite any 
portion of Carre that describes a library of data types expressed in an abstract syntax 
notation. Additionally, Carre's CMISE Gateway, which the Examiner equates to the 
metadata gateway of Applicants' claims, does not include a library of data types. Carre 
makes no mention of his CMISE Gateway including a library of data types expressed in 
an abstract syntax notation. Instead, Carre describes his CMISE Gateway as providing 
address type conversion between two different object interface specifications, such as 
between IDL and C++. Merely providing address type conversion does not imply 
including a library of data types and a plurality of object type, each including one or more 
of the data types from the library. The Examiner's interpretation of Carre's CMISE 
Gateway is incorrect. 

Additionally, Carre also fails to disclose wherein the metadata gateway includes 
an interface to the plurality of object types , wherein the interface is operable to provide 
one or more clients with access to the metadata as expressed in the interface definition 
language. The Examiner has not cited any portion of Carre that describes the CMISE 
Gateway, which the Examiner equates to the metadata gateway of Applicants' claims, as 
including an interface to a plurality of object types, where the interface provides clients 
with access to the metadata. Carre's CMISE Gateway translates objects and object 
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address types from ASN to IDL and from DDL to ASN. Nowhere does Carre describe 
that the CMISE Gateway includes an interface providing clients access to metadata. 

Thus, for at least the reasons above, the rejection of claim 17 is not supported by 
the prior art and removal thereof is respectfully requested. 

Section 103(a) Rejection : 

The Examiner rejected claims 6, 13, 15 and 16 under 35 U.S. C. § 103(a) as being 
unpatentable over Carre (U.S. Patent 5,758,186) in view of Kung et al. (U.S. Patent 
6,775,267) (hereinafter "Kung"). Applicants respectfully traverse this rejection for at 
least the reasons presented above regarding their respective independent claims. 

Regarding both the § 102 and § 103 rejections, Applicants also assert that 
numerous ones of the dependent claims recite further distinctions over the cited art. 
However, since the rejection has been shown to be unsupported for the independent 
claims, a further discussion of the dependent claims is not necessary at this time. 

Request Pursuant to M.P.E.P. § 707.02 : 

Applicants note that this is the fourth different rejection asserted in this 
application without any substantive amendment having ever been made to any of the 
independent claims. Applicants also note that this application has been pending for well 
over five years. Pursuant to M.P.E.P. § 707.02, Applicants request that a Supervisory 
Patent Examiner review this application "with a view to finally concluding its 
prosecution." According to M.P.E.P. § 707.02, this application "should be carefully 
studied by the supervisory patent examiner and every effort should be made to terminate 
its prosecution. 55 As noted in Applicants 5 remarks above, the application is clearly in 
condition for allowance. If there are any questions concerning the allowability of the 
present application, Applicants' undersigned attorney earnestly requests a telephone 
conference with the Supervisory Patent Examiner to expeditiously resolve any 
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outstanding issues. Applicants also note that according to M.P.E.P. § 707.02, this 
application "is to be considered 'special' by the examiner." Applicants strongly object to 
the "piecemeal examination" that has been applied to this application. See M.P.E.P. § 
707.07(g). 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any extension of time (under 37 C.F.R. § 1.136) is necessary to prevent the 
above-referenced application from becoming abandoned, Applicants hereby petition for 
such an extension. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 
501505/5181-46200/RCK. 

Also enclosed herewith are the following items: 
£3 Return Receipt Postcard 

□ Petition for Extension of Time 
O Notice of Change of Address 

□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: January 3 L 2006 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 
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